home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000734_rik@daneel.rdt.monash.edu.au _Tue Mar 9 00:32:49 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <rik@daneel.rdt.monash.edu.au>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA12797; Tue, 9 Mar 93 00:32:49 MET
  4. Received: from daneel.rdt.monash.edu.au by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA06598; Tue, 9 Mar 1993 00:50:23 +0100
  6. Received: by daneel.rdt.monash.edu.au (5.57/Ultrix3.0-C)
  7.     id AA28984; Tue, 9 Mar 93 09:49:00 +1000
  8. Message-Id: <9303082349.AA28984@daneel.rdt.monash.edu.au>
  9. To: joe@athena.mit.edu
  10. Cc: www-talk@nxoc01.cern.ch, tk-WWW@athena.mit.edu
  11. Subject: Re: Any thoughts on exec: URL? 
  12. In-Reply-To: Your message of "08 Mar 93 09:37:59 EST."
  13.              <9303081437.AA21416@theodore-sturgeon> 
  14. Date: Tue, 09 Mar 93 09:48:59 +1100
  15. From: Rik Harris <rik@daneel.rdt.monash.edu.au>
  16. X-Mts: smtp
  17.  
  18. > In the next version of tkWWW, I'm planning to include an "exec:" URL
  19. > header.  If you select a tag with this header it will display the text
  20. > at the end of the address and ask the user if it wants to execute it
  21. > as a system call.
  22. > 
  23. > Any thoughts?  In particular, are there any security problems won't be
  24. > fixed by asking the user whether or not to execute the command before
  25. > doing so?
  26.  
  27. This is bringing the security problem down on the knowledge of the
  28. user, which has never been a good idea (otherwise, password systems
  29. would _work_).  If the users don't understand what a command does, some
  30. will never execute them (which is admittedly no worse than the current
  31. situation), and some will always execute them, which doesn't provide
  32. any security.  I can see the neophytes looking at the box that popped
  33. up with some gibberish, and saying that the Web is too complicated,
  34. and then going back to gopher ;-)
  35.  
  36. Also, this will be extremely client specific.  There's no advantage in
  37. including the same extension in non-unix clients, as the exec will not
  38. work in (say) VMS or MS-DOG.  I'd like to see clients converge
  39. towards a standard (or at least, have a standard converge towards
  40. the clients), but this is not possible if URL's will only be useful
  41. for one OS.  It would also be annoying to maintain a different Web for
  42. different clients.
  43.  
  44. You could probably make it work by designing a meta-language, that
  45. could be implemented by each client.  This way, you can build the
  46. security in from the start, and not worry about unknowledgeable
  47. users.
  48.  
  49. rik.
  50. --
  51. Rik Harris - rik.harris@fcit.monash.edu.au              || Systems Programmer
  52. +61 3 560-3265 (AH) +61 3 565-3227 (BH)                 || and Administrator
  53. Faculty of Computing and Information Technology,        || Vic. Institute of
  54. Clayton Campus, Monash University                       || Forensic Pathology